雖然 Compose for Desktop 團隊已經把打包 App 的工作用 Gradle 簡化,但長期維護 App 時,總不能每次發佈新版本時,就手動執行 Gradle Task 打包吧?若考量到多個作業系統平台、同時維護多個版本,排列組合後的工作量就會非常驚人了。
這時就是導入 CI/CD 的最佳情境了!
今天的耕讀筆記,會使用 TeamCity 這套由 JetBrains 推出的 CI/CD 主機,建置一個 Compose for Desktop 的自動化發佈流程。
TeamCity 是由 JetBrains 所推出的 CI/CD Solution,它是一個由 Server 與 Agent 組成的分散式架構,使用前需要先把主機架設起來。要架設 TeamCity 主機有幾種方式:
若使用軟體包或是 Docker 建置 TeamCity 主機,在第一次啟動時,別忘了依照筆者「首次啟動設定」的步驟完成初始化,方便後續能順利的使用喔!
接著要在 TeamCity 裡,將專案的 Pipeline 建立起來,並設定每當有新的程式碼 Push 到 Repository 時,會自動觸發 TeamCity 執行建置工作,並打包安裝執行檔,省下所有手動操作的時間與人工。
請登入 TeamCity 後進入主畫面,點選左上方 Project 右邊的加號(+
)建立一個新專案。
TeamCity 支援從 GitHub、Bitbucket、Gitlab 等程式碼代管平台匯入 Repository,也可手動輸入 URL 匯入。
接著設定專案在 TeamCity 上的 Project 名稱、Build Configuration 名稱、及 VCS 相關設定,一般來說若沒有特別的需求,使用 TeamCity 自動偵測的設定值即可。
TeamCity 會自動掃描 Repository 內有可能使用的 Build Tool,以 Compose for Desktop 預設的範例專案來說,掃描後 TeamCity 就抓到 Gradle、IntelliJ IDEA Project、Command Line 三種。由於 Kotlin 專案大多使用 Gradle 為主,因此這一步勾選 Gradle 後選 Use selected 後進入下一步。
選擇 Gradle 後,TeamCity 會自動建立預設的 Build Configuration,並在 Pipeline 裡建立預設的 Build Step,也就是執行 clean
及 build
的 Gradle Task。
不過以 Compose for Desktop 專案來說,我們不只要編譯(build
)程式碼,還要打包應用程式,因此我們要修改這步 Build Step。點選右邊的 Edit 連結進入 Build Step 編輯畫面,修改 Gradle tasks 從 clean build
改為 clean package
、設定 JDK 版為 JDK 17,完成後按 Save 儲存。
設定好回到 Build Configuration 頁後,就可以點擊右上角的 Run 按鈕執行第一次的建置工作。TeamCity 會將畫面帶到 Build/Queue 頁,我們可以在畫面上觀看 Build 的執行過程。 等到整個 Build 完成後,雖然結果是成功的(綠色),但切到 Artifacts 頁籤時,卻會發現沒有留下打包的檔案,這是因為我們沒有設定當 Build 完成後,要把什麼檔案留下來。點擊右上方的 Edit configuration 按鈕,我們要調整專案設定。
進到專案的 Build Configuration 設定裡的 General Settings,設定畫面上的 Artifacts paths 為 +:build/compose/binaries => distribution.zip
。其中 +:
表示 Build 完成後要抓取的路徑,=>
表示要把抓取路徑的資料夾壓縮成壓縮檔,後面接的 *.zip
是輸出的壓縮檔檔名。設定完成後,按 Save 儲存,再點擊右上角的 Run 按鈕重新執行一次 Build。
等新的 Build 完成後,再切到 Artifacts 頁籤,就會看到打包之後的 distribution.zip
檔案,下載下來就會是當時 App 最新打包的結果。
經過以上簡單的設定,以後只要 Repository 有新的 Commit,TeamCity 就會自動幫我們把最新版的程式碼抓下來編譯,並打包成可安裝執行的檔案,就不需要開發者手動在自己的電腦上完成這些工作了!